Eecient Demultiplexing of Incoming Tcp Packets Sqn Tr92-01

When a transport protocol segment arrives at a receiving system, the receiving system must determine which application is to receive the protocol segment. This decision is typically made by looking up a protocol control block (PCB) for the segment, based on information in the segment's header. PCB lookup (a form of demul-tiplexing) is typically one of the more expensive operations in handling inbound protocol segments Fel90]. Many recent protocol optimizations for the Transmission Control Protocol (TCP) Jac88] assume that a large component of TCP traac is bulk-data transfers, which result in packet trains JR86]. If packet trains are prevalent , there is a high likelihood that the next TCP segment is en route to the same application (i.e. uses the same PCB) as the previous TCP segment. In these environments a very simple one-PCB cache like those used in BSD systems yields very high cache hit rates. However, there are classes of applications that do not form packet trains, and these applications do not perform well with a one-PCB cache. Examples of such applications are quite common in the area of heads-down data entry into on-line transaction-processing (OLTP) systems. OLTP systems make heavy use of computer communications networks and have large aggregate-packet-rates but are also characterized by large numbers of connections, low per-connection packet rates, and rather small packets. This combination of charac-teristcs results in a very low incidence of packet trains. This paper uses a simple analytic approach to examine how diierent PCB lookup schemes perform with OLTP traac. One scheme is shown to work an order of magnitude better for OLTP traac than the one-PCB cache approach while still maintaining good performance for packet-train traac.